| 翻訳者の言葉。

こんにちは、私は現在、Twitterの広告APIの開発の前に、TubiでAkkaとScalaでAdServerを構築しています。

私はよ。経済学部卒からシリコンバレープログラマーへ。記事では、Twitter を離れる前に、Twitter の広告プラットフォーム グループが AdServer (広告サーバー) のマイクロサービスリファクタリングを開始し、プロジェクト名 Project Tao (Dao) を作成しました。 1 年以上にわたり、Twitter は広告プラットフォームのリファクタリングを完了し、ブログ投稿 Accelerating ad product product development at Twitter でこのプロセスを文書化し、AdServer での作業にインスピレーションを得ました。 限られた知識をもとに全文を翻訳し、ローカルに書き換えた。

この記事では、より多くの広告のドメイン知識とバックエンド開発技術について説明します。 広告サーバーの構築に興奮している場合。面白い、同様に私たちにお気に入りや個別のメッセージを残して、私は広告サーバーの導入の次の導入で入門します。また、ようこそ。同じ名前に注目してください。アカウントを知っている。！

コンウェイの法則は、「組織のアーキテクチャは、システムのアーキテクチャを決定する」と述べています。Twitterの広告チームも例外ではありません。2010年には、約15人のエンジニアと2,800万ドルの収益を上げ、2019年には数百人のエンジニアに成長し、約34億ドルを稼いでいます。Twitterの広告システムの機能と複雑さは、チームやサービスの運用モデルが大幅に変化していない間、この間増加しています。

チームの初期のシステム アーキテクチャは、スタートアップに適しており、以前の意思決定の負担を脇に置き、迅速に反復するのに役立ちます。 広告のバックエンドは、大きく3つのチームに分かれています。 プラットフォーム(Platform)、科学、製品(Product)。 チームの最終的な目標は、Twitter が収益を上げるのを助けるために、広告製品を迅速に構築し、反復処理することです。

Twitterの広告プラットフォームは、AdServer、課金、データインフラ、アナリティクスなどのシステムを含むインフラストラクチャとコアコンポーネントで構成されています。 このうちモノリシック・アドバンス(モノリシック・アド・サーバー)は、広告プラットフォームの中核サービスです。 Twitter クライアントから広告リクエストを取得し、ユーザー情報と広告主のターゲティング条件に基づいて広告プールの候補広告をランク付けし、最も適格な広告を除外し、次値オークションを行い、最終的にユーザーに最も関連性の高い広告を応答として送信します。

チームの分業では、プラットフォーム チームは、信頼性が高く高性能なモノリシック AdServer を構築し、展開と oncall の責任を担います。 製品チームの焦点は、Twitterのフロントエンド製品チームのニーズに応じて、AdServerで変更することです。 基本的に、プラットフォーム チームは、変更とサービスを完全に制御する通関の役割を担います。 製品チームは、プラットフォーム チームの管理下で、コード ベース全体を変更します。

このモデルに基づいて、Twitterは、さまざまな目標と複雑さを持つ成功した広告製品を作成しました。 Promoted Tweets(プロツイート)は、ブランドが幅広いオーディエンスにリーチし、ブランド製品の認知度を高めるのに役立つ最初のサービスです。 Promoted Trend (マイクロブログ検索のようなプロモーショントレンド) は、ブランドがすべての Twitter ユーザーの探索欄を 1 日で占有できるようにします。 Mobile App Promotion (モバイル アプリ プロモーション) は、広告主が宣伝するモバイル アプリをダウンロードするようユーザーに促します。 Web Clicks (ページ クリック) は、ユーザーがブランド サイトにアクセスすることを奨励します。 Promoted Video は、ブランドがストーリーテリングしやすいメディアである動画を通じて宣伝し、広告のリーチと効果の測定をサポートします。

このモデルは、小規模なエンジニア チームで非常にうまく機能し、反復速度が速くなります。 しかし、ビジネスとチームの成長に伴い、プラットフォーム チームは機能イテレーションのボトルネックになり始めています。 これをよりわかりやすくするために、広告リクエストのプロセスの概要を次に示します。

1. 広告リクエストのワークフロー。

最も関連性の高い広告を提供するために、Ad Mixer とモノリシック AdServer という 2 つのコンポーネントを広告リクエスト パスで使用します。

Ad Mixer は、ad サーブパイプラインのゲートウェイ (ゲートウェイ) サービスです。 クライアントからの広告リクエストを受け取るたびに、次の処理が行われます。

• 要求をモノリシック AdServer に転送し、AdServer から広告応答候補を受け取ります。

• オークションの結果に基づいて表示する広告を決定するサブ価格オークションを実行します。

• 表示される広告の情報を保存し、ユーザーが広告と対話する方法に基づいて広告主に請求します。 たとえば、ユーザーが広告を閲覧した場合、Twitter は広告主に x ドルを請求します。 ユーザーが宣伝されたアプリを閲覧してダウンロードした場合、Twitter は広告主に x+y ドルを請求することがあります。 )

モノリシック AdServer は、各要求について、適格な各広告を考慮し、AdMixer に最適な候補広告を返します。 Twitter 広告製品のサイズを考慮すると、このサービスはシャードであり、各シャードは候補広告のサブセットのみを考慮します。 また、このシャード スキームにより、広告要求の遅延に関する厳しい要件 (200 ~ 500 ミリ秒) を満たす並列コンピューティングも可能になります。

翻訳者注: 分割前に広告要求のワークフロー。

翻訳者注: ここでは、広告の 3 つのレベル構造を簡単に理解する必要があります: 広告グループ/campaign - 広告プラン/line item - 広告クリエイティブ/creative。 1 つの広告グループは 1 ~ 複数の広告プランに対応し、1 つの広告プランは 1 ~ 複数の広告クリエイティブに対応します。 広告グループは「ナイキヨガギア2020秋プロモーション」などのプロモーションについて説明しています。 広告プランには、通常、「男性プロモーション」「女性プロモーション」「キッズプロモーション」など対象グループの説明が含まれており、それぞれ3つの対象グループに対応する。 広告クリエイティブの説明は、動画、ポスター、またはテキストなど、具体的に表示する内容を示します。

各 AdServer シャードは、広告候補のサブセットに基づいて、次の手順を実行します。

• 広告の候補選択。 年齢、地域、興味など、関連性のない広告をユーザーから除外し、対象となる広告プランを除外します。 たとえば、女性ユーザーからの要求がある場合は、男性プロモーションに関する広告プログラムを削除します。 )

• 広告クリエイティブの拡張と製品ロジック。 Twitter の製品ルール (製品の種類によって異なる) に基づいて、各候補広告プログラムを広告クリエイティブのセットに拡張し、製品ルールに従ってさらにフィルタリングします。 (注: 広告クリエイティブに候補広告を拡張するプロセスには、AdServer が広告プランのターゲティング情報やユーザー情報に基づいて、AdServer が広告取引所などの第三者に入札を依頼し、動的な見積もりやクリエイティブ情報を取得するリアルタイムオークション(Real-time bidding)が含まれる場合があります。 )

• 候補広告ランキング (早期フィルタリングを含む)。 製品ロジックフェーズの後、ユーザーが広告をクリックする可能性(リアルタイムトレーニングの機械学習モデルを呼び出す)、広告主の入札情報、オークションの特性に基づいて、候補広告を評価し、ランク付けします。

2010 年から 2018 年にかけて、AdServer のロジックはますます複雑になっています。 結果は次のとおりです。

• 各展開には数百の変更が含まれています。

• プラットフォーム チームは AdServer を管理していますが、AdServer の主な変更は製品チームによるもので、2 つのチームが 「相互に制約」されました。

さらに、AdServerのいくつかのステップの間に明確な境界はなく、広告クリエイティブの拡張と製品ロジックに属するコードが「候補広告選択」または「候補広告ランキング」に追加されないようにするための効果的なメカニズムが欠如しています。 明確でない境界は、製品チームのエンジニアにさらなる複雑さをもたらします: モノリシック AdServer はブラックボックスであり、コンポーネント間の強い結合、どの部分が不足しているか、AdServer は機能しません。 製品エンジニアは、AdServerのローカルのみを理解しており、テストが困難です。 開発から展開、運用環境への導入まで、単純な変更に 1 か月かかる場合があります。

トランスノート:モノリシックAdServerのロジックは複雑です。

2. 広告製品機能のライフサイクル。

2018年は、上記のプラットフォームチームと製品チームの構造に基づいて、ビデオ広告製品機能のライフサイクルは次のとおりです。

| コード考古学。

| デザイン。

| コンサルティングプラットフォームチーム。

| 」を公開。

コードがレビューに合格し、マージされると、製品チームはプラットフォーム チームに再度依存して展開する必要があります。 新機能のテストは、多くの場合、1 つの展開に最大 200 個の変更を含む困難です。 さらに、複数の製品のロジックが同じ強力に結合されたモノリシック AdServer で実行されるため、1 つの間違った変更によって展開全体がブロックされ、他の製品チームに影響を与える可能性があります。 最終的なテストはリリース後まで完了し、異なるチームの関与が必要なため、バグのバグを修正するタイミングは予測が困難です。

3. ソリューション。

| 製品のリザーバを導入し、製品のイテレーションを加速します。

我々は、多くの点でこれらの問題を解決します。 まず、さまざまな広告製品にサービスを提供するインフラストラクチャ コンポーネントを分離します (たとえば、サービス Selection Service の選択、ランキング サービス Ranking Service など)。 さらに、製品チームの反復速度を向上させる鍵は、製品入札を導入し、乗算効果を維持するために異なる製品の入札者がフレームワークを共有することです。 (注: 分割された AdServer を bidder と名付けることは、入札が AdServer の重要なリンクであるため、製品間の入札ロジックによって大きく異なる可能性があります。 )

翻訳者注: 分割後、広告要求のワークフロー。

モノリシック サービスの各モジュールを 1 つのマイクロサービスに分割すると、製品の反復効率が大幅に向上するように見えますが、サービス間の変更が頻繁に発生し、開発効率が低下します。 したがって、分割プロセス中に、適切なトレードオフを行いました。

• モノリシック AdServer を異なる「製品入札」サービスに分割し、各製品品種の「ベスト」広告を返します。 たとえば、ビデオオークションは最高の動画広告のみを返す責任があり、モバイル アプリ プロモーション オークションは最高のモバイル アプリ プロモーション広告のみを返す責任があります。 したがって、各入札者は、独自の展開リズム、oncall、パフォーマンス、および運用特性を持つことができます。

• AdServer コードベースを入札者フレームワークと製品固有のロジックに分割し、各入札者の実装は、入札者フレームワークと製品ロジックの構成可能な組み合わせです。

翻訳注: 分割された AdServer パイプライン。

| 入札フレーム。

上の図に示すように、各パイプラインには、Filter と Enricher などの複数の手順が含まれています。 入札フレームワークは、このパイプラインの構造と実行メカニズムを定義し、各製品の入札者は、特定の製品要件に応じてカスタマイズすることができます。

このアプローチにより、サービスと製品が分離されるため、プラットフォーム チームは入札者フレームワークのみを担当し、製品チームは入札の具体的な実装を担当します。 乗数効果を維持しながら、開発の俊敏性と速度を最大化します。 たとえば、フレームワークのアップグレードは、すべての製品入札者で同時に機能し、すべての製品入札者は分析データ収集メカニズムのセットを共有します。

| データ依存フレームワーク。

| シャード サービスのデータの取得と転送。

注: Ad Mixer でデータグラブを実行します。

以前のシステムでは、Ad Mixer は広告要求ごとに必要なデータ (ユーザーの個人情報、関心、アクティビティなど) を 1 回取得し、個々のシャード AdServer にデータを渡します。 分割後、各入札者は異なるデータソースを必要としますが、分割された各サービスは、データの取得を400倍に増加させる可能性があるため、個別にデータを取得しないようにしたいと考えています。 Ad Mixer で 1 回限りのデータ取得を行い、次の方法を使用して、入札者が必要なデータを効率的に取得できるようにしました。

• 型チェックを必要としないデータについては、パススルー(passthrough)を実装し、中間サービスは、データの形式や内容を知らなくても、指定されたダウンストリームサービスに元のバイトを転送することしか担当しません。 (注: パススルーはシリアル化を回避し、データ転送コストを削減します。 )

• 型検査が必要なデータについては、パッケージの漏洩を回避し、ダウンストリーム サービスがデータを誤って使用しないように、型チェックを行う必要があるデータを分類し、コンシューマにラベルを付けます。 データの消費者を動画広告オークションャーとしてマークした場合、モバイルアプリプロモーション広告オークションのロジックはデータを消費しません。 )

3. 課題と経験。

| 信頼性の高い段階的な移行。

分割する前に、TwitterのモノリシックAdServerは30億ドル相当の広告ビジネスを実行していました。 そのため、分割を行いながら、既存事業を継続して運営し、継続的な製品開発を支援する必要があります。

プロジェクトでは、新しいシステムによってトラフィックの小さな部分をサポートし、元のシステムによってトラフィックの大部分をサポートし、製品指標を徹底的に分析し、2つのシステムが収益と指標にほぼ準拠していることを確認し、通常の広告ビジネスに影響を与えることなく、問題を早期に発見したい、広範なA/B実験を実施しました。

4週間の期間にわたって、新しいシステムへのトラフィックの割合を徐々に増加させ、新しいシステムに追加しました。 さらに、製品の入札者ごとに約 20% の容量を展開し、30 秒以内にロールバックを完了するメカニズムを有効にしました。 最後に、四半期にわたるトラフィックの小さな割合を以前のモノリシック AdServer で実行し、指標に対する季節的な影響を調査しました。

| コードの複雑さ。

| 隠されたバグを公開します。

過去 8 年間、チームは AdServer に段階的な変更を加えてきましたが、大きなバグを見つけるのが難しいという欠点があります。 この分割は、システムに根本的な変更を加え、ソフトウェアに潜むバグを発見するのに役立ちます。 バグの発見、診断、修正には四半期かかりますが、システムの健全性は高まっています。

4. トレードオフ。

どのソリューションも万能ではなく、当社のチームは、この決定のリスクとメリットを十分に認識し、次の「トレードオフ」を行います。

| 候補広告のグローバルランクを作成する能力を失います。

モノリシック AdServer を複数の製品オークションに垂直に分割すると、各製品の入札者が候補広告のランキングを個別に表示します。 その結果、AdServe 内ですべての候補広告をグローバルに近い方法でランク付けする能力が失われました。 私たちは、長所と短所を認識し、最終的なオークションで考慮される候補広告の数を増やすことによって、ローカル意思決定の損失を補い、当初の適格な候補広告を除外しないようにすることにしました。 (注: 動画広告とカード広告の 2 つの広告商品があり、それぞれ 10 の候補広告があるとします。 グローバル最適の 5 つの広告のうち、4 つの動画広告と 1 つのカード広告があるとします。 ローカルランキングで動画広告とカード広告をそれぞれ上位3位に引き上げ、集計後にグローバルランキングを行うと、動画広告を誤ってフィルタリングします。 Twitter は、それぞれ上位 5 位を獲得することで、これを減らすことができます。 )

| ダウンストリーム サービスのトラフィックが増加します。

AdServerの規模を考慮すると、プロジェクトの開始時にサービスのトラフィックを見積もり、6か月前にインフラストラクチャ チームに通知します。 いくつかのプロトタイプと大量のストレステストを使用して、見積もりの精度を確保しました。

| リリース プラットフォームの変更のリリース サイクルが長くなります。

AdServer を製品別に分割すると、各プラットフォーム レベルの変更がすべての製品でテストおよびリリースされる必要があります。 私たちは、このコストを認識し、喜んで負担します。

上記の欠点が存在する場合でも、入札者アーキテクチャが正式に稼働した後、製品分離の利点が見られます。 具体的な例として、Promoted Trend の選択サービスにキャッシュを構成することで、他の製品の動作に全く影響を与えることなく、遅延を低減します。 また、製品機能のイテレーションがプラットフォーム チームによってブロックされなくなり、主要な問題点が解決されることがわかります。

5. 要約。

すべての法則には限界があり、コンウェイの法則も例外ではありません。 これは、すべての組織に適用されますが、我々はまた、サービスや組織が将来のニーズに適合し、歴史に縛らされていないことを確認するために協力することができます。 すべての問題を解決できるわけではありませんが、チームやサービスにプラスの影響を与え、新しいアーキテクチャに新しい機能を追加する製品エンジニアのワークフローが簡素化されます。 このプロジェクトを始めたとき、それはほとんど不可能な作業だったようですが、振り返ってみると、より健康的なシステムを構築するだけでなく、システムの仕組みへの理解を深め、Twitter広告部門の次の野心的な目標を達成するための基盤を築いたのです。

メッセージエリア。